fix(ci): report override keys too narrow to cover a vulnerable copy - #2174

Six defects from review on the first version of this change, all real:

Parent-scoped keys claimed to cover copies under any parent. splitOverrideKey
discarded the parent, leaving the child selector-less, so it read as covering
everything. Live here: react-native>jest-environment-node has no blanket
sibling, so every jest-environment-node in the tree looked covered. Coverage
now checks the parent against the advisory's dependency paths, and credits the
key only when no path information exists.

Partial comparator bounds were zero-padded rather than expanded. semver reads
'>1' as "from 2.0.0" and '<=1.2' as "all of 1.2.x"; padding got both backwards,
calling 1.5.0 covered by '>1' and 1.2.5 uncovered by '<=1.2'.

An ordinary selector matched a prerelease, so an exact pkg@1.2.3 key was read
as covering 1.2.3-alpha.1. semver and pnpm both exclude it, so the override
would not actually apply and a vulnerable prerelease could pass unreported.

x-ranges fell through to the catch-all, so uuid@8.x was treated as covering a
7.0.3 copy. uuid@8 and uuid@8.x are one intent; handling only the first left
the same blind spot one syntax along.

Suggested keys were derived from the first version token of patched_versions.
For a disjoint range like '<2.0.0 || >=2.0.5' that produced "<2.0.0": "2.0.0",
which misses a vulnerable 2.0.3 and pins copies outside the patched set. A
suggestion is now offered only for a simple lower-bounded range.

Baseline keys joined the uncovered versions in audit order, so an accepted
entry went stale the day pnpm listed them differently. Sorted now. The baseline
file also documented only the stale-pin shape, so following it for an
uncovered-copy produced an entry that could never match; both shapes are now
documented with examples.

109 tests pass. Each fix was verified to fail the suite when reverted. The real
uuid case is still caught and still suggests "uuid@<11.1.1": "11.1.1", and
simulating fresh advisories on nine real escaping pinned targets still yields
11 stale pins and 0 uncovered copies.

An exact prerelease selector matched nothing above it and fell to the
permissive fallback, so a key like pkg@1.2.3-alpha.1 read as covering every
version in the tree. Measured: selectorCovers('1.2.3-alpha.1', '9.9.9') was
true. It is a point and is now compared as one.

Parent-scoped coverage used paths.some, so one matching path credited the key
for the whole version. The same version can arrive both under the scoped
parent and elsewhere, and the occurrence the override cannot rewrite was then
suppressed. Every path must go through the parent now.

The success line claimed every override pins a patched version whenever
nothing was unaccepted, which is also true when findings are merely baselined.
That contradicted the accepted-drift block printed directly above it and read
as falsely reassuring. It now reports no unreviewed findings and says how many
accepted entries are still vulnerable.

81 tests pass, 109 across test:scripts. Each fix verified to fail when reverted.

Five more from review, two of them mistakes in the previous round's fix:

Coverage of a version is "for EVERY path, SOME key covers that path". Folding
the `every` into overrideKeyCovers inverted that, so two sibling keys like
foo>child and bar>child each failed on the other's path and the pair was
reported as leaving an uncovered copy it actually covers. Split into a per-path
predicate with the version-level quantifiers in versionIsCovered.

Parent matching compared substrings, so key foo>child was credited for the
path 'app > foobar > child@1.0.0'. Segments are now compared by package
identity, with or without a version suffix.

The prerelease gate only ran in the bare/x-range branch, so pkg@<2.0.0 and
pkg@^1.0.0 still claimed to cover 1.2.3-alpha.1. semver keeps a prerelease out
of every ordinary range, so the check moved to the top of selectorCovers and a
selector that names a prerelease is the documented exception.

A patched range of '>1.2.3' means the fix is ABOVE 1.2.3, but the suggestion
regex accepted it and fixedVersionFrom then proposed pinning to the still
vulnerable 1.2.3. Only '>=' names a pastable release now.

'pkg@>v1.2.3' and 'pkg@> 1.2.3' were read as parent>child, indexing the entry
under 'v1.2.3' and skipping every advisory for pkg. A '>' preceded by '@', '<'
or '>' is always an operator.

87 tests pass, 117 across test:scripts. The real uuid case is still caught with
the same suggested key, and the nine real escaping pinned targets still produce
zero uncovered copies.

Review found four more defects in the hand-rolled comparator, on top of the
four in the previous round. Every one was a silent false negative in a
security check:

- a caret or tilde selector carrying a prerelease matched no branch and fell
  to the permissive fallback, so pkg@^1.2.3-alpha.1 covered every version
- prerelease identifiers were compared lexicographically, so 1.0.0-alpha.10
  sorted below 1.0.0-alpha.2 and <1.0.0-alpha.2 claimed to cover alpha.10
- a compound range like >=1 <2 was waved through as covering everything
- partial comparator bounds and prerelease eligibility each needed their own
  special case, and each was wrong before it was fixed

Eight defects across four rounds is the approach failing, not bad luck. This
swaps the whole comparator for semver, which is what pnpm resolves with. The
dependency-free constraint turned out to be self-imposed rather than a repo
rule: scripts/ci already imports istanbul-lib-* for coverage.

Also fixes two findings semver does not cover:

- a pnpm parent selector overrides the matched parent's OWN dependency, so
  foo>child cannot reach a child that an intermediate package depends on.
  The path check now requires the parent to sit directly before the child
  rather than anywhere in the ancestry.
- the uncovered-copy remediation text claimed the pin was patched and
  promised a suggested key even when none was printed, which happens for a
  no-fix, disjoint or exclusively bounded patched range. It is now conditional,
  and the no-suggestion case says to read the advisory instead.

91 tests in this file, 121 across test:scripts. Behaviour on the real data is
unchanged: the uuid case is still caught with the same suggested key, and the
nine real escaping pinned targets still produce zero uncovered copies.

semver.coerce was used only as a truthiness guard before validating the
original strings, so it never changed the outcome and made the comparison
harder to read. Validate directly instead. Unorderable input still sorts
equal rather than throwing, since one malformed audit version should not
abort the whole check.

… header

Three more from review.

A version-scoped parent key was reduced to its bare name, so `foo@1>child`
was credited for a path through foo@2.0.0. pnpm applies such a key only when
the parent's own version satisfies the selector, so a patched pin could
suppress a copy the override never rewrites. The path check now tests the
parent's version too, and passes when the path carries no version to compare.

The parent separator was told apart from the range operator by the character
AFTER the '>', which rejected any child whose name starts with a digit. `2fa`
is a real package name, and `foo>2fa` was indexed under the literal string
rather than the child, skipping every advisory for it. The operator is
identified by the character before the '>' instead, which is always one of
@ < > or =.

The header still described the hand-rolled comparator, the dependency-free
constraint and compound and x-ranges being unrecognised. The previous commit
replaced all of that with semver, so the documented contract was wrong about
the check's own false-negative policy. Rewritten to match.

93 tests here, 123 across test:scripts. Each fix verified to fail the suite
when reverted.